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14. As to Claims 3 and 13, Wagner teaches the drive model further includes means for calculating 
mathematical modules for driving at least one signal interface and wherein said module generates real- 
time signals in order to obtain said interface signals in accordance with the simulated sensor/actuator 
components at the interface connection pins (Page 487, section III, lines 9-17 and Figure 5, 
"Simulation Computer"). 

15. As to Claims 4 and 14, it is concluded that since components in a design must be mounted on a 
printed circuit board, the controller as shown in Wagner Figure 5, being an actual hardware component, 
must be mounted on a printed circuit board. Further, it is concluded that a design on a printed circuit 
board will include interface connections to any system that is needed to realize the design, allowing 
connection to the interface pins in the component that will be receiving or transmitting signals to the 
system. 

16. As to Claims 5,6,15, and 16, Wagner teaches signal interface has an output stage that can 
function to output power or receive power. Figure 5 shows the signal interfaces providing two-way 
communication between the simulated models and the controller. Further, page 488, column 1, section 
A, lines 3-10 state that the PSI and ABI signal interfaces perform signal conditioning which is applied to 
outputs from the controller or from the RTS, signifying that this interface functions to output power (from 
the RTS) or receive power (from the controller). 

17. As to Claims 7 and 17, Wagner teaches said drive model comprising a computer for providing 
an equivalent circuit of the sensor/actuator component as said model (page 481, column 2, lines 3-9). 

1 8. As to Claims 8 and 18, Wagner teaches said model is adapted to signals required at an interface 
connection pin by utilizing specific parameters (page 488, column 2, second paragraph, lines 11-14) as 
an example, wherein the commanded motor current is measured by the interface unit and supplied as 
input to the motor driver model executing in the simulation computer. 

19. As to Claims 9 and 19, Wagner teaches a fault simulation module for generating one of a line 
interruption and a short circuit (Figure 5, "Failure Module" and page 488, column 2, last paragraph). 

20. As to Claims 10 and 20, Wagner teaches each signal interface has a regulating circuit for 
adjusting one of voltage and current to a value specified by said model (page 488, column 1, section A, 
paragraph 1, section A, paragraph 2, lines 3-14). 

21 . As to Claim 11 and 12, Wagner teaches the regulating circuit includes a feedback arrangement 
to the drive module in order to provide actual values of regulated variables to said model (page 488, lines 
11-20). 
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22. The prior art made of record and not relied upon is considered pertinent to applicants disclosure. 

23. Raman et al (Raman et al, "Design and Implementation of HIL Simulators for Powertrain Control 
System Software Development". Proceedings of the American Control Conference, June 1999, pages 
709-713) teach a hardware-in-the-loop simulation system including actuator and sensor models. 
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unsuccessful, the examiner's supervisor, Kevin Teska can be reached on 703-305-9704. The fax phone 
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Information regarding the status of an application may be obtained from the Patent Application 
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A Strategy to Verify Chassis Controller 
Software — Dynamics, Hardware, and Automation 

John R. Wagner and John F. Keane, Member, IEEE 


Abstract — A real-time hardware-in-the-loop tool set is pre- 
sented to test automotive chassis controllers. The use of high- 
speed computers, specialized hardware interfaces, and instrumen- 
tation, as well as simulation models and automation software, 
provide a realistic and repeatable laboratory environment to 
supplement in-vehicle testing. In this paper, the dynamics for a 
variety of chassis models are presented to support the verification 
of integrated controller hardware and software. To implement 
these mathematical descriptions the computer hardware, labo- 
ratory equipment, and simulation software are discussed. The 
automated testing features of the simulator permit the creation 
of script files and test suites for regression testing and reuse 
on similar programs. A number of issues such as simulator 
requirements, hardware interfaces, and the need for metrics are 
explored in order to facilitate the development and justification 
of a simulation capability. 


Nomenclature 

a Distance from GG to front axle, (m). 

ttoff Vertical pressure center long, offset, (m). 

Ad Cross sectional area, (m^). 

AT Wheel aligning torque, (N*m). 

AT Aligning torque, ({>J*m}/rad). 

b Distance from CG to rear axle, (m). 

c Half of front wheel track, (m). 

Co Lateral tire stiffness, (N/rad). 

CofiCa^ Front, rear total cornering stiffness, (N/rad). 

Cd Aerodynamic drag coefficient. 

Wheel damping coefficient, 

({N*m}/{rad/s}). 

CG Center of gravity. 

d Half of rear wheel track, (m). 

Suspension pitch damping, (N/{m*rad/s}). 

de Shock absorber roll damping, 

(N/{m*rad/s}). 

D Rolling tire resistance, (N). 

D Rolling resistance, (N). 

e x-distance from king pin to wheel CG, (m). 

/ y-distance from king pin to wheel CG, (m). 

-fcoui Suspension Coulomb damping force, (N). 

Fd Aerodynamic drag force, (N). 

-^damp Suspension viscous damping force, (N). 

Fg Suspension force, (N). 

■^spring Suspension spring force, (N). 
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ner@eng.delcoelectxom). 
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Fxxv Longitudinal tire force in wheel plane, (N). 

Fx Tire force along forward body axis, (N). 

Fyyj Lateral tire force in wheel plane, (N). 

Fy Tire force along lateral body axis, (N). 

F^ Normal tire load, (N). 

AF^ Vertical load transfer, (N). 

EFx Sum of longitudinal forces, (N). 

EFj, Sum of lateral forces, (N). 

g Acceleration constant, (m/s^). 

h Center of gravity height, (m). 

Distance from wheel center to ground, (m). 

ha Distance from CG to aerodynamic force, (m). 

hg Height of sprung mass CG above roll axis, 

(m). 

ia^ ia Actual and estimated motor current, (amps) 

ic,ic Commanded and measured motor current, 
(amps). 

^c,orioi Serial value of commanded motor current. 

Iwy Wheel inertia about spin axis, (kg*m^). 

Ix Sprung mass inertia about roll axis, (kg*m^). 

Ixz Vehicle inertia about x and z axes, (kg*m^). 

lyy Vehicle inertia about pitch axis, (kg*m2). 

Ixz Vehicle inertia about yaw axis, (kg*m^). 

ks Suspension roll stiffness, ({N*m}/rad). 

k^ Suspension pitch stiffness, (N/{m*rad}). 

m Total vehicle mass, (kg). 

TUa Sprung mass, (kg). 

TiMx Sum of moments about roll axis, (N*m). 

EMy Sum of moments about pitch axis, (N*m). 

EM^ Sum of moments about yaw axis, (N*m). 

R Undeflected tire radius, (m). 

Re Effective radius, (m). 

Sx Longitudinal wheel slip. 

t Time, (s). 

ta Distance between vehicle longitudinal center 

line and shock absorber, (m). 

Tfc Wheel brake torque, (N*m). 

Td Wheel driveline torque, (N*m). 

UjUi Longitudinal vehicle, wheel center speed, 

(m/s). 

Uxu Wheel center speed in wheel plane, (m/s). 

v, Vi Lateral vehicle, wheel center speeds, (m/s). 

V Velocity, (m/s). 

Wx Vehicle roll angular speed, (rad/s). 

Wy Vehicle pitch angular speed, (rad/s). 

Vehicle yaw angular speed, (rad/s). 

X Body fixed longitudinal axis. 
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X Global vehicle longitudinal position, (m). 

y Body fixed lateral axis. 

Y Global vehicle lateral position, (m). 

Y Vehicle side force, (N). 

z Body fixed vertical axis; height of roll axis 

above ground at axle, (m). 

Z Global vehicle vertical position, (m). 

a Tire side slip angle, (rad). 

P Vehicle sideslip angle, (rad). 

6 Steer angle of wheel, (rad). 

7 Wheel camber angle, (rad). 
fx Friction coefficient. 

a; Angular velocity of the wheel, (rad/s). 

p Mass density of air, (kg/m^). 

0 Vehicle pitch angle, (rad). 

6 Vehicle roll angle, (rad). 

tp Vehicle yaw angle, (rad). 

e Roll steer [38 /d9}, (rad/rad). 

{dAT/da} Change in aligning torque versus slip, 
({N*m}/rad). 

[dD/dFz] Change in rolling resistance with load, (N/N). 

{dL/dwj;} Roll damping produced by the shock ab- 
sorbers, {N*m*s}/rad). 

{dY/d^} Camber thrust per unit camber angle, (N/rad). 

{d^/dO} Rate of wheel camber angle change with 
respect to body roll angle, (rad/rad). 

Subscripts: 

b Brake. 

fail Failure. 

/,r Front, rear axles. 

z,j ith, jth wheel and axle location. 

1, 2 Right, left front wheels. 

3, 4 Right, left rear wheels. 


I. INTRODUCTION 

THE application of on-board electronic controllers to mon- 
itor and regulate automotive systems offers the consumer 
improved vehicle performance. Powertrain controllers mon- 
itor all major engine and transmission fiinctions to realize 
significant reductions in tailpipe emissions with minimum 
adverse effects on fuel economy and vehicle driveability. Body 
and chassis control systems (e.g., antilock brakes, real-time 
suspension damping) provide increased safety and ride comfort 
to the vehicle occupants through improvements in directional 
stability and steerability [1]. Traditionally, the development 
process for automotive systems has involved extensive in- 
vehicle testing and evaluation. However, the competitive de- 
mands of the marketplace are requiring automotive companies 
to reduce cycle time and development costs. The application of 
hardware-in-the-loop (HIL) technology to the controller design 
process can reduce expensive field tests, improve product 
quality, facilitate examination of subsystem interactions, and 
resolve critical safety issues prior to in-vehicle testing [2]. In 
particular, the system level verification and validation of inte- 
grated chassis controller hardware/software to the customer's 
requirements can be automated in a laboratory setting with 
HIL tools. 


A HIL simulator permits an automotive controller to be 
operated in an environment electronically equivalent to the ac- 
tual vehicle (refer to Fig. 1). The simulator contains electronic 
circuits which provide electrical loads representative of those 
found in an actual vehicle. A high-speed computer is interfaced 
to the controller through the actuator and sensor emulation 
hardware. The computer executes dynamic system models to 
calculate the vehicle's response and generate sensor signals for 
the driver inputs and controller commanded actuator signals. 
Thus, a dynamic coupling is established between the controller 
and the simulated vehicle. In this paper, the hardware and 
software elements of an automotive chassis simulator are 
presented. Section II provides an overview of various vehicle 
subsystem models. The simulation computer and laboratory 
hardware are presented in Section III. In Section IV, the 
software utilities necessary to automate the testing process, as 
well as several methods to verify controllers, are discussed. 
Section V presents experimental and simulation results to 
provide insight into the application of the tool set. A number of 
key simulation issues are discussed in Section VI that should 
be addressed early in the development process. 

II. S[MULAT[ON OF CHASSIS DYNAMICS 

The creation of a model-based automotive simulation re- 
quires the availability of empirical and analytical mathematical 
descriptions of the system components. As shown in Fig. 2, 
the chassis dynamics are generally composed of the vehicle, 
wheel, brakes, steering, suspension, tire/road interface, driver, 
environment, and in some instances, powertrain dynamics. 
The vectors Xi have been introduced to permit the primary 
output elements from each subsystem to be denoted. For 
instance, the brake system block has the output vector X2 
which includes the brake pressures and torques for each 
brake channel. The inputs to this subsystem include the 
variables from the engine, transmission, and engine control 
module {Xi), the ABS/TCS controller (Xg), and the driver 
{Xio) blocks. Models for each of the vehicle's subsystems 
should be available with varying degrees of sophistication. 
The complexity of a component model may then be selected 
in order to create a simulation tailored for the application that 
is not overly excessive. This is an important issue in real- 
time simulations where a tradeoff often exists between model 
fidelity and execution speed requirements. In the paper by 
Allen and Rosenthal [3], vehicle dynamics model requirements 
are summarized for various types of simulations. The chassis 
models presented in this paper are sufficient for software 
verification. 

The environment block contains software modules which 
allow the road surface properties and elevation to be var- 
ied as functions of the vehicle's location. For instance, a 
composite road surface may be characterized by specifying 
the ftiction coefficients in a position indexed lookup table 
[4]. The vehicle's global position is then used to determine 
the nominal coefficient of finction for each wheel. In the 
driver block, vehicle maneuvering information is described 
through traditional driver commands. These commands may 
be generated by the user during run-time by manipulating the 
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Fig. 1. Conceptual goal for hardware- in-the- loop testing. 



* m^* ^ i^iimrfljh «i>f^ 


Fig. 2. Schematic for simulating chassis dynamics. 


hardware interface, or stored a priori through the use of script 
files to automate the system's operation. 


A. Vehicle and Suspension Dynamics 

The motions of a vehicle may be categorized in terms of 
performance and ride, as well as handling and stability. The 
performance and ride characteristics focus on the longitudinal 
and heave motions of the platform, respectively. The stability 
and handling characteristics generally refer to the vehicle's lat- 
eral/directional response due to steering maneuvers. A variety 
of low, medium, and high-order models are available to de- 
scribe the automobile's translational and rotational dynamics. 

I) Low-Order Models: A one degree-of- freedom (DOF) 
vehicle model is sufficient in cases where a lumped mass 
approach is acceptable to generate the platform's speed. The 


equation of motion in the longitudinal direction is 

mu = SFx (I) 

This description has been successfully used in powertrain 
simulations which require only an approximate speed to em- 
ulate the vehicle's speed sensor for engine algorithm testing. 
However, limitations in the vehicle dynamics preclude the use 
of this model in chassis controller studies. 

A two DOF model is presented for lateral stability investi- 
gations. In this analysis, the vehicle's front and rear wheels are 
collapsed into a single front (steerable) and rear wheel with 
negligible inertia. Also, the roll and weight transfer effects are 
neglected. This "bicycle" model permits the lateral/directional 
response of the platform to be examined for small angle 
steering maneuvers at constant longitudinal speed [5]. Body 
fixed (xyz) and global {XYZ) coordinate systems are used 
to describe the dynamics (refer to Fig. 3). The equations of 
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Id 


pitch ^ 


y body axis 



z body axis 


(rear) 


Fig. 3. Axis system for simplified vehicle models. 


Direction of x* 
wheel travel , Direction of 
* * wheel heading 



-C„.<w, 







h' 





V7777 

{R > R^> h') 


Fig. 4. Directional geometry and rotational wheel dynamics. 


motion for forces along the y-axis and moments about the 
z-axis are 


m{v 4- uwz) = SFy 


(2) 
(3) 


As shown in Fig. 4, the wheel is rolling at a slip angle a 
which represents the angle formed between the direction of 
wheel travel and wheel heading. The front and rear slip angles 
become 

af = {v awz}/u — 6f ar = {v ~ bwz}/u. (4) 

In some cases, a front and rear roll steer effect (e^) may also 
be included in the slip angle expressions. From this figure, 
P = {v/u} represents the vehicle sideslip angle. To further 
simplify the analysis, it is assumed that the slip angles are 
small (sin a = q) and that the lateral tire forces are linear 
functions of the slip angles. If the lateral accelerations are 
greater than approximately 0.4 g's, then this final assumption 
may no longer be acceptable. The summation of lateral forces 
and moments about the yaw axis is 


In these equations, the cornering stiffness has a negative 
magnitude since a positive slip angle produces a negative 
lateral force acting on the tire [6]. However, in some references 
(e.g., [7]), the cornering stiffness has a positive magnitude 
resulting from its definition as the negative of {dFy/da}. 
Equations (2) and (3) may be numerically integrated to yield 
the lateral and yaw velocities in the local coordinate system. 
These body axis velocities may be transformed into velocities 
in the global reference system by 

X = ucos^ — vsin^ Y — usintp-hvcostp (6) 

where ip is numerically integrated from ^ = Wg. Finally, the 
vehicle's position in global coordinates may be determined by 
integrating the expressions in (6). 

2) Medium Order Models: A three DOF model is presented 
to describe the longitudinal, lateral, and yaw motions of an 
automobile undergoing maneuvers [8]. This model combines 
vehicle kinematics, tire forces, and wheel dynamics to create 
a general purpose simulation suitable for preliminary antilock 
brake system (ABS) and traction control studies. The equations 
of motion are 


i:Fy = C^^Of-\~Ca^ar T,M, = aCa,as''bCc.^ar. (5) 


(7) 
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in the longitudinal direction and (2) and (3). From Fig. 3, the 
external forces acting on the vehicle are 

4 

1:F^ = ^ - Fd {where = O.SQp^rfU^} (8) 

i-l 

Sfy = E^«<- (9) 

i-l 

The summation of moments about the yaw axis are 

EM, = a{Fy, + F^J - biFy, + Fy, ) 

+ c(F,,-FxJ+d(F,, -Fx3). (10) 

in this expression, the aligning torques have been neglected 
and should be added if required. Equations (2), (3), and (7) 
may be numerically integrated to determine the lateral, yaw, 
and longitudinal velocities in the body axis coordinate system. 

The speed of each wheel center in the wheel plane may be 
calculated as 

Utui = Ui cos Si -{-Visindi (11) 

where the longitudinal and lateral velocities at each comer of 
the vehicle are given by 

Ui =u-\' {—lycwz Vi=v-{^awz (i = l, 2) (12a) 
Uj =u-{-{-iydw:, Vj = v~bwz (j = 3,4). (12b) 

Again, the vehicle velocity may be transformed from the local 
coordinate system into the global reference system using the 
transformations in (6). 

For completeness, a model developed by Segel [9] which 
analyzes lateral vehicle motion in response to steering inputs 
will be discussed. The assumptions for this model include 
a constant forward velocity, small lateral accelerations, and 
symmetry about the x-axis which allows a single front and 
rear wheel to be considered. The equations of motion for the 
sideslip, roll, and yaw in a two mass (sprung and unsprung) 
system with an inclined roll axis are 

m{v + uwz) H- TTishsWx = T,Fy ( 1 3) 
/xti^z + rnghsiv + uw^) + IxzWz = EM^; (14) 
hz'djz + IxzVJx = SM^ . (15) 

The lateral forces acting on the platform are 

EFy = f/ + y, (16) 

where 

Yi = Ca,ai -\- {dYi/dyi}{d^i/dO}0 

includes the cornering force and tire camber effects. The 
chassis characteristic {dji/dS} is experimentally measured for 
the vehicle. The torques contributing to the roll moment are 

EM, = {m,g)hsQ + {ke^ + ke^e -f [{dL/dw^} / 

+ {dLldw^)r\wx, (17) 


In this expression, the roll damping produced by the shock 
absorbers may be approximated as {dL/dwx}i = 2dQ.tl^, 
The summation of torques for the yaw moment are 

EMz = {aVj - hYr) + { AT/ + ATr) + 2{cD / + dDr) ( 1 8) 

where 

Ari^{dATildai}ai and Di = {dDi/dFz,}£!^Fz,. 

The load transfer AF^. may be calculated as Ci{YiZi + 
ke,0 + [dL/dwx}iWx) with Ci = l/{2c} or l/{2d} de- 
pending on whether the front or rear axle is under consid- 
eration. In the expressions for YijATi, and the terms 
{dYi/d'yi}:{dATi/dai}, and {dDi/dF^,} are empirically 
defined tire characteristics (Section II-B), Equations (16)-(18) 
may next be expressed as functions of {fi^Wz^O^Sf^Wx)- The 
resulting differential equations are traditionally solved with 
classical methods to study the influence of various design 
parameters on the vehicle's stability. The reader is referred 
to the reference by Mola [10] for fxirther information. 

A four DOF model is presented to describe the longitudinal, 
lateral, yaw and pitch motions of an automobile. This model 
provides a general purpose description of the vehicle dynamics 
which can serve both powertrain and chassis applications well. 
The equations of motion are 

IyyWy=EMy (19) 

and (2), (3), and (7). The summation of forces and moments 
(refer to Fig. 3) are (9) and 

4 

EFx = -mg sin + ^ F^, - Fa (20) 

i=l 

EM, - a{Fy, + ) - b{Fy, + J + c{Fx, - F^, ) 
-^d{Fx,-Fx,) 

4 

- e{Fy, + Fy,) + /(F:,. -F^,) + '^ATi (21) 

4 

EMj, = -o(F,, + F,,) + 6(F,3 4- + ^ hF^, + haF^. 

(22) 

The transformations to calculate the yaw, pitch, and approxi- 
mate roll angular velocities, based on Wy and Wz^ are 

ijj = Wz ^ = Wy 9 = Wz(f>^ (23) 

These expressions may be numerically integrated to calculate 
the yaw and pitch, as well as approximate roll, angles. In 
a similar manner, the transformations to compute the global 
velocities 

X ='Ucos^cos^ — vsintp Y = vcosip -h usin^cos^ 
Z = -usm<f> (24) 

may be integrated to determine the global positions. 

Depending on the intended application of the simulation, 
the model for the suspension forces may be simplistic or quite 
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complex. Generally, a suspension model will include spring 
forces as well as viscous and Coulomb damping forces 


F'sf — -^spring; "i" ^daxnpi ~^ ^ zouU • 


(25) 


The suspension springs (coil, leaf, or torsional bars) support 
the weight of the car and characterize the ride behavior of 
the platform. The spring force is a nonlinear function of the 
suspension's deflection. Frequently, a series of linear regions 
are considered over the range of vertical travel to approximate 
the nonlinear behavior. For the four DOF vehicle model, the 
front and rear spring forces can be represented as {a(j>)k^^ 
and —{b<p)k<i,^ where A;^ may be interpolated from a lookup 
table or further approximated by a constant magnitude. The 
term Fjamp represents the hydraulic shock absorbers (or 
struts) which dampen the vehicle's motion. In many analyzes, 
these viscous damping elements are modeled as ideal fluid 
dampers whose force is proportional to the suspension's rate of 
deflection. Again, the nonlinear damping force versus velocity 
curve may be approximated by straight line segments. The 
front and rear damping forces can be represented as {awy)d^j. 
and —{bwy)df^^ where may be determined in a similar 
manner to A;^. Finally, the coulomb damping force is also a 
function of the suspension's deflection rate. This fi-iction force 
is quick acting and has a saturation feature normally described 
by limit ftinctions. In some applications the rubber bushings, 
which act as vibration isolators to minimize transmission of 
higher frequency oscillations, and/or anti-sway bars may also 
need to be considered in the suspension model. 

3) High-Order Models: If a more sophisticated vehicle de- 
scription is needed to study dynamic interactions, then a 
higher order model using sprung and unsprung masses is 
recommended. Two vehicle stability and control simulations 
are available to study handling and braking capabilities for 
a range of maneuvers. The simulation by Garrott and Scott 
[11] considers a three mass system — sprung, front unsprung 
and rear unsprung. The sprung mass has six DOF (three 
translations and three rotations). The unsprung masses each 
have two DOF if the wheel spins and steering dynamics are not 
counted. The front unsprung mass has two translations relative 
to the sprung mass to describe the wheel hop. For the rear 
unsprung mass, the independent suspension model includes 
two suspension deflections while the solid axle description 
considers one suspension deflection and one axle roll. Overall, 
this vehicle model provides a comprehensive description of the 
system dynamics. The second model has been developed by 
Allen et al. [12] to analyze vehicle lateral/directional control 
and stability. In this model, a three mass system is also 
considered. The sprung mass has four DOF (longitudinal, 
lateral, yaw, and roll) while each unsprung mass has two DOF, 
again not counting the wheel spins and steering dynamics. 
For the front and rear unsprung masses, the roll and vertical 
motion of the respective axles are considered. In addition to 
modeling the vehicle dynamics, these two simulations provide 
descriptions for the wheels, suspension, steering, and tire/road 
interface. 

An important issue in the development of real-time sim- 
ulations is the tradeoff between model sophistication and 
execution speed. Ideally, all the system dynamics may be 


adequately addressed when developing a model. However, 
real-time requirements may challenge the engineer to exclude 
some dynamics in order to achieve a mathematical description 
which may be computed in real time. Associated with this issue 
is the correlation, or level of accuracy, of the simulation to the 
physical system for a specified operating range. Heydinger et 
al. [13] has proposed a statistical based validation methodol- 
ogy which requires multiple experimental and simulation runs 
at each test condition to gather data for both frequency and 
time domain analysis. A series of qualitative (e.g., overlaying 
plots) and quantitative (e.g., steady state gain, peak frequency) 
strategies are presented to compare the test measurements and 
simulation predictions. 

B. Tire/Road Interface 

The shear forces and aligning torques generated at the 
tire/road interface must be computed to simulate the wheel and 
chassis dynamics. To quantify the impact of applied braking or 
driving torques on a wheel, the tire's side slip angle and wheel 
slip are calculated. As shown in Fig. 4, a local coordinate 
system [x^j/, z') has been attached to the wheel with its origin 
at the center of tire contact. Although the side slip angle was 
introduced in (4), the expression is now stated as 

ai = taa~^(i;i/ut) - 5^. (26) 

The longitudinal wheel slip is defined in two manners depend- 
ing on whether the wheel is accelerating or decelerating 


drive slip: s^^ = {ynui - Rei^^i) / Ra^i 
brake slip: s^i = (wti/i - Ra^iM'^wi' 


(27) 


To calculate the shear forces and aligning torques, the normal 
tire load must also be available. In the model proposed by 
Dugoff etal [8], the static loading and quasistatic load transfer 
due to pitching, as well as the quasistatic approximation of 
the dynamic load transfer due to the vehicle's roll angle, are 
considered 

= 0.5< I :— ^ 1 I -bmg ^hY^J^.^haF^ 


\ 1 
, a h 


+ (-l)^^*+^>(A:.,/{fc., 4-fc,.})(/iF^/c)| {j = 1,2) 

(28a; 

+ {-l)^'^'\kBj{kej + keMhFyld)^ {j = 3, 


4). 
(28b) 

Generally, the traction forces for a variety of road surfaces 
and operating conditions may be generated using two strate- 
gies: extrapolation of empirical data, and analytic models. In 
the first method, experimentally gathered tire data is loaded 
into look up tables and an extrapolation scheme [14] is 
implemented to describe road conditions that are not explicitly 
contained in the test data. Frequently, experimental tire data 
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is limited to a few road surfaces (e.g., dry asphalt, asphalt 
with thin water film) and operating conditions (e.g., side 
slip angle, normal load). From this experimental data, the 
longitudinal tire force versus wheel slip provides a measure of 
the braking/driving force coefficient {Fx/Fz}. The lateral tire 
force versus slip angle graph provides the cornering stifftiess 
Ca = {dFy/da}a=o- The aligning torque versus slip angle 
and camber thrust versus camber angle graphs can yield 
{dAT/da} and {dY/d^}, respectively. Finally, the tire's 
rolling resistance versus vertical load at a specified forward 
velocity provides the quantity {dD/dFz}. 

The second strategy uses mathematical models to estimate 
the mechanical performance of pneumatic tires from basic 
design and operating variables. These models range from 
simple linear descriptions useful in deriving and analyzing 
control systems to nonlinear representations [15]-[17] with 
tire lag [18]. The tire forces and aligning torque are calculated 
based on the longitudinal wheel slip, wheel speed, side slip 
angle, normal load, and other variables (e.g., camber angle). 
These forces in the wheel plane may be transformed into 
longitudinal and lateral forces in the vehicle coordinate system 
by 

Fxi = Fxwi cos5i-Fyu,( sinSi F„,. = Fi„,. siii^f+F„u;i cos^i 

(29) 

C W^heel Rotational Dynamics 

The forces and torques acting on the ixh wheel from the 
transmission, brakes, road surface, vehicle, and wheel bearings 
are shown in Fig. 4. The summation of moments about the 
spin axis are 

I^yUi = + Ta, + Fx^.h' - F,,aoff - C^.iJi. (30) 

Several approaches may be used to calculate the wheel speeds, 
including the direct integration of the rotational dynamics 
and a closed form solution based on the linearized ^-sUp 
curve. In the first method, (30) is numerically integrated. 
However, these dynamics are very fast compared to the overall 
vehicle dynamics which can result in stiff differential equations 
(i.e., system eigenvalues vary widely in magnitude). This 
phenomenon arises from the large mass and moments of 
inertia for the vehicle in comparison to the small rotational 
inertias of the wheels and large torques experienced from the 
braking, driveline, and ground forces. If the high-frequency 
wheel dynamics are not properly handled, then numerical 
instabilities may arise. A number of solutions are available to 
avoid numerical integration stability problems. First, reduce 
the integration time step as allowed by the execution speed 
constraints. Second, select a numerical integration method 
with accuracy and stability characteristics suitable for the 
application. Improved accuracy may be realized by using 
smaller time steps or by selecting a higher order integration 
algorithm. However, higher order integration methods may 
have smaller stability regions which will require smaller in- 
tegration time steps. Third, consider restricting the simulation 
to avoid unstable domains of operation. For instance, an ABS 
simulation might terminate when the vehicle velocity falls 
below some specified threshold (e.g., V <1 MPH). Although 


this solution may be acceptable for ABS simulations since 
control algorithms cease operation in this region, it is probably 
not optimal in traction control studies where low vehicle 
velocities are of interest. 

The second strategy to simulate the wheel spin dynamics is 
based on the work by Bernard [19], The nonlinear tire traction 
torque is linearized about the operating point /xq by considering 
a Taylor series expansion of the continuously differentiable 
^-slip curve with higher order terms neglected (i.e., fx = 
/io+{^M/^5x}{5x-5xo}). This permits a closed form solution 
of the first order wheel slip equation to be obtained, thus 
eliminating the need for numerical integration. The underlying 
principle of the state transition approach may be used in other 
simulation applications where the differential equations do not 
readily lend themselves to numerical integration. 

D. Brakes and Steering Dynamics 

A base brake model should include descriptions for the 
pedal linkage, vacuum booster, master cylinder, brake lines, 
and brake discs or drums [20]. The pedal linkage transmits the 
driver's applied force to the vacuum booster which amplifies 
this force using vacuum from the engine's manifold. The 
master cylinder, attached to the vacuum booster, transforms 
the amplified force into hydraulic pressure by displacing brake 
fluid through the fi^ont and rear brake lines. Proportioning 
values distribute the pressure properly between the front and 
rear axles. The front and rear brakes convert the pressure into 
a friction force to decelerate the wheel. Although the brake 
system is nonlinear with dead zones, approximate models (e.g., 
pure time delay, first order linear dynamics) are fi*equently 
used to describe the system's response. However, nonlinear 
models of the vacuum booster, master cylinder, engine mani- 
fold, and proportioning values have been developed (e.g., [21] 
and [22]) which offer improved accuracy. 

The steering module maps the steering wheel inputs into 
fi-ont wheel displacements. Manual steering systems contain 
a steering wheel and column, a gearbox and pitman arm or 
a rack and pinion assembly, linkages, steering knuckles and 
wheel spindles [23]. Power steering systems add a hydraulic 
pump and power steering gear assembly. In the model derived 
by Segel [24], a distributed mass steering system is reduced to 
a lumped mass description with compliance, Coulomb friction, 
and viscous damping. The inputs are the driver applied steering 
torque and kingpin torque due to the tire/road interface, 
while the output is the front wheel displacement. The model 
proposed by Garrott and Scott [11] calculates the front wheel 
steering angles and steering connecting rod displacement as 
functions of the steering wheel angle, moments on the wheels 
about the kingpins, linkage geometry and stiffness, and gear- 
box ratio. In some instances, the steering system dynamics may 
be avoided by assuming an infinitely stiff steering mechanism 
and by directly providing the fi-ont wheel displacements. 

£. Engine and Transmission Dynamics 

A variety of models have been derived to describe the 
behavior of spark ignition (SI) and diesel engines for sim- 
ulation and control purposes. A comprehensive survey has 
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Fig. 5. Hardware-in-the-Ioop simulator configuration. 


been conducted by Powell [25] on internal combustion engine 
models for control system design. The engine descriptions 
may be broadly divided into input-output and physical-based 
models. Multi-input multi-output models are generated by 
applying system identification techniques to the experimental 
data (e.g., [26]). The resulting transfer functions are dependent 
on the specific system configuration, and require engine data 
to be available over the full operating spectrum. The physical- 
based models consider fundamental laws governing the flows, 
thermal transients, and accelerating inertias to describe the 
behavior of the system components. For real-time HIL test- 
ing, the lumped parameter mean value engine models (e.g., 
[27]-[33]) may be selected as the basis for engine simulations 
due to the satisfactory accuracy and limited complexity. For 
diesel engine models, the reader is referred to the work by 
Benson [34], Watson [35], and Kao and Moskwa [36]. A 
number of subsystems are generally considered in a tur- 
bocharged diesel engine description including the compressor, 
intercooier, intake manifold, engine and crankshaft assembly, 
exhaust manifold, turbine, and turbocharger rotor. 

Analytical and empirical models in the simulation library 
describe the fuel injectors, throttle body, intake manifold, com- 
bustion process, and rotational dynamics for SI engines [37]. 
The fuel injector model converts the controller commanded 
solenoid fuel pulses into a mass of sprayed fiiel. The throttle 
body model computes the mass air flow rate into the intake 
manifold based on the throttle valve angle, idle air control 
actuator position, and pressure ratio across the throttle. The 
intake manifold dynamics distribute and delay the flow of 
gases from the throttle body and EGR valve into the engine 
cylinders with attention to fuel transport characteristics, if 
appropriate. The combustion model generates the indicated 
torque based on the mass of air, air/fuel ratio, spark timing, and 
exhaust gas in each cylinder. Finally, the crankshaft torques 
(e.g., indicated and load) are summed, integrated, and divided 
by the crankshaft inertia to yield the engine speed. 

An automatic transmission transfers and regulates the en- 
gine's power to the drive wheels based on the vehicle's traction 
requirements. A number of models and analysis methods 
have been proposed to describe the behavior of vehicle trans- 
missions. The interested reader is referred to the references 
by Benford and Leising [38], Kotwicki [39], and Cho and 


Hedrick [40]. The transmission modules in the simulation 
library include the torque converter, transmission gearbox, 
and differential [37]. The torque converter provides a fluid 
coupling between the engine and the drivetrain to dampen 
out disturbances, prevent engine stalling, and provide torque 
multiplication during vehicle acceleration. To describe these 
dynamics, the empirical based torque converter models gen- 
erate the pump and turbine torques based on their respective 
speeds. Included in this subsystem are the torque converter 
clutch models which describe the mechanical linkage of the 
pump and turbine. The automatic transmission gearbox models 
describe the motions of the planetary gears, clutches, and 
bands which together provide different torque multiplication 
ratios based on the engine load conditions. The differential 
models contain the kinematics of the gears which provide 
additional torque multiplication, transmit the output torque to 
each axle, and allow different axle rotation speeds. 


III. Simulation Computer and Laboratory Hardware 

The real-time HIL simulation facility has been designed to 
test and analyze automotive controllers. As shown in Fig. 5, 
the facility consists of a simulation computer, various hard- 
ware interfaces, and controller instrumentation. The simulation 
computer is an Applied Dynamics Real Time Station (RTS) 
with an attached System 100 input/output (I/O) rack. The 
computer hardware is based on the open architecture of the 
VMEbus with distributed processors to execute the simulation 
models and handle network communications [41], The RTS 
contains multiple Motorola 88110 based compute engines to 
solve the analytical and empirical mathematical descriptions of 
the system components. In the current configuration, the I/O 
rack contains analog-to-digital converters, digital-to-analog 
converters, and digital input/output lines. These intelligent 
I/O modules contain Motorola 68040 support processors for 
parallel computing of interface operations such as signal 
conditioning and linearization. The availability of commercial 
I/O modules to emulate automotive sensors should minimize 
the need for specialized hardware interfaces, A local 300 MB 
disk can support high-speed data recording and playback in 
real time during and after a simulation. 
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Users can access the RTS, a server attached to the local area 
network, from their workstations connected to the ethemet. In 
our facility, Sparcstations 20 (model 50) are used to control 
and monitor the simulation, as well as provide an integrated 
environment for algorithm development and data analysis. The 
RTS compute engines can be programmed in C, Fortran, or 
Adsim [42]. A rapid prototyping capability is available to 
move quickly from block diagrams and software simulations 
(using Integrated Systems* MATRIXx product family) to HIL 
applications on the RTS. The high-level language Cosim is 
used to schedule, synchronize, and control communications for 
the parallel processors. Interactive run time software provides 
an environment to acquire simulation data, and to monitor and 
control the simulation from the user's workstation. 

A. Hardware Interfaces 

The hardware interfaces are designed to create an electronic 
environment equivalent to the vehicle. Ideally, the controller 
should be unable to distinguish between vehicle and laboratory 
operation. Thus, a controller should receive the expected inputs 
(e.g., commanded throttle position, wheel speeds) necessary 
for normal operation, while also delivering the required outputs 
(e.g., fuel injectors, transmission force motor). As shown 
in Fig. 5, the powertrain simulation (PSI), antilock brake 
(ABI), and motor load (MLI) interfaces provide the electrical 
transitions needed to connect controllers to the I/O rack. 

The PSI contains circuitry designed to accommodate engine 
and transmission controllers, while the ABI electronics are 
targeted for chassis controllers. The PSI and ABI perform 
three types of operations on the I/O signals that pass between 
the controller and the RTS: analog and digital signal condi- 
tioning, the conversion of signals to different formats, and 
interconnection without modifying the signal. The first type 
of operation, signal conditioning, is applied to outputs from 
the controller (e.g., high-side drivers) or the RTS (e.g., low- 
side switches). An example of the second type of operation is 
the conversion of a pulse width modulated controller output 
to a voltage proportional to its duty cycle. In the third 
category, circuits pass select unconditioned controller signals 
(e.g., serial data) to an output port. An important consideration 
for the circuits in the first two categories is the provision 
of electrical loads equivalent to those found in an actual 


vehicle. However, these electrical loads cannot be easily 
adjusted to permit the introduction of signal shorting or noise 
disturbances. Consequently, a failure mode interface (FMI) has 
been designed. An attractive feature of the PSI is the ability 
to select between a front panel or RTS automated mode of 
operation to control the generation of signals. The user may 
either drive the HIL simulation by manually manipulating 
the simulator's switches and potentiometers, or place it under 
computer supervision (Section IV-A) to execute a test profile 
composed of driver commands. 

The MLI provides an electrical load and interface circuitry 
between ABS VI controllers and the simulator. The electro- 
hydraulic ABS VI modulator regulates brake pressure in each 
channel (left front, right front, and rear) using a dc motor 
attached to a power screw which extends/retracts a piston to 
push/pull brake fluid. The MLI allows the simulator to exercise 
the controller's software in a realistic manner while applying 
reasonable electrical loads to the controller's hardware. This 
interface uses a static resistor-inductor (RL) network to load 
the motor driver circuits thus permitting the controller to 
realize its commanded motor current. During a simulation, 
the commanded motor current ic is measured by the MLI 
and provided as input ic to the motor driver model executing 
on the simulation computer (refer to Fig. 6). This model is 
coupled with descriptions of the dc motor, ABS modulator, 
and vehicle to calculate the estimated "actual" motor current 
la, as well as the brake pressure and the chassis' response. 
To accept the "actual" motor current feedback signal from the 
simulator, rather than from the on-board motor driver circuit, 
the controller hardware must be modified (i.e., cut and jump). 
The MLI's approach to simulating dc motor loads through the 
use of static loads on the driver circuits and hardware-intrusive 
feedback avoids the difficulties associated with emulating the 
back-emf in hardware while retaining the effects of a dynamic 
load on the controller. 

The FMI provides a computer supervised method for the 
hardware-based manipulation of the controller I/O. This instru- 
ment is positioned between the three hardware interfaces and 
the controller so as to modify the cable harness signals. The 
FMI provides two basic operations — signal shorting and signal 
summation. The signal shorting circuit offers four options for 
an input signal C: closed circuit, open circuit, short to ground, 
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and short to battery. The signal summation circuit introduces 
four capabilities for two input signals, A and B: closed and 
open circuits for A, replacement of A with B, and signal 
summation (A-hB). An important feature of this instrument 
is the ability to automate its operation. High-level software 
directives may be specified in scheduler files to regulate each 
circuit, as well as to generate the additive or auxiliary signal B. 

B. Controller Instrumentation 

The Modular Development System (MDS) has been de- 
veloped by Delco Electronics to support software testing 
and calibration activities. This instrumentation provides three 
primary capabilities when connected to a controller: emulation 
of program and data memories, high-speed data acquisition, 
and internal data logging. A personal computer (PC) provides 
the interface between the user and the MDS. The PC uses 
PC/NFS software to access the ethemet and permit remote 
operation of the instrumentation. The architecture of MDS 
enables the instrumentation's RAM, which emulates the con- 
troller's ROM, to be asserted in the controller's address space. 
Thus, the PC to MDS path allows the transfer of files (e.g. 
program code, calibration sets) to the instrumentation, thereby 
providing an alternative to programming controller memory 
devices (e.g., EPROMS). 

The high-speed data acquisition and internal data log- 
ging capabilities of MDS are important tools for software 
development. By overlaying the controller's RAM with instru- 
mentation RAM, the MDS captures data from the controller 
without disturbing its operation. The data is logged to a 4 MB 
RAM buffer in the computer interface buffer with internal 
logging (CIBIL). To synchronize flight recording operations 
for multiple data acquisition systems, an external triggered 
input and a system triggered output are available. During a 
test, the preselected controller variables are logged, processed, 
stored in RAM, and displayed on the PC or vacuum fluorescent 
display unit. At the conclusion of the test, this information may 
be transferred from the CIBIL to the Sun workstation, 

IV. Automating the Controller Test Process 

The development of software utilities to automate the con- 
troller testing process enhances the attractiveness of simulation 
tools. A computer supervised scheduler enables the controller 
inputs and simulation events to be prescribed in a repeatable 
manner through script files. To record the controller's response 
to this stimuli, data is logged from both the simulator and 
controller with the integrated data acquisition scheme (Section 
IV-B). Several test methods have been developed to facilitate 
the systems level verification and validation of integrated 
controller hardware and software. 

A. Scheduler Utility and Test Scripts 

The scheduler utility has been developed to schedule spe- 
cific events (i.e., controller inputs, driving scenarios, and/or 
instrumentation operations) in a time indexed manner. This 
utility reads the user specified inputs or recorded in-vehicle 


test data firom the designated scheduler file and, at the appro- 
priate time instances, updates its outputs. A schedule file also 
contains information to direct the operation of the simulation 
environment and control the data acquisition process. Each file 
chronologically lists the simulation variables to manipulate, 
with their prescribed profiles, and the controller and RTS 
variables to be acquired through data acquisition. During 
execution of a simulation, the designated schedule file contents 
are loaded into the simulation and interpreted by the scheduler 
utility. The scheduled variables' signals are generated by the 
utility's software-based fianction generator (e.g., step, saw 
tooth) at the times specified for each variable. 

To support a variety of driving profiles and test procedures, 
a number of schedule files must be created. In most instances, 
a schedule file is designed to verify one requirement in the test 
plan. Thus, a logical extension to the schedule file concept is 
the creation of test suites for systems and software verification. 
The grouping of these files into a series of test suites, perhaps 
organized by software functions or features, facilitates regres- 
sion testing (i.e., selective retesting of a system to ensure that 
a software change has not caused unintended effects in another 
area). Ideally, the schedule files and test suites developed for 
one program will be directly applicable to future programs. 

B, Integrated Data Acquisition 

An integrated data acquisition strategy has been created to 
time synchronize the data from the controller instrumentation 
and the simulation computer (refer to Fig. 5). Controller 
hardware and software may be effectively investigated by 
analyzing the controller's internal variables, external I/O, 
and appropriate simulation variables. For instance, a split 
coefficient braking maneuver can be established using the 
scheduler utility. An ABS control algorithm's performance to 
this operating scenario may then be recorded and evaluated 
by logging controller data (e.g., estimated wheel slips) via the 
instrumentation, plus the vehicle dynamics (e.g., yaw angle) 
and controller I/O (e.g., wheel speeds) via the simulation 
computer. 

The Sun workstation is the. final destination for the RTS 
and MDS data. During a test, simulation data is continuously 
acquired through the RTS data acquisition utility and written 
to a workstation file. Meanwhile, controller variables are 
logged to the CIBIL and stored in RAM. In addition, the 
instrumentation sends synchronization signals to the RTS to be 
included with the simulation data. Once the test is completed, 
the MDS recorded information is transferred to the workstation 
and writtenTo another file. These two data files are aligned and 
merged to create a single data file that documents the test. 

C. Controller Test Strategies 

The simulation facility provides a powerful tool for the ver- 
ification (i.e., the process of evaluating a system to determine 
whether the products of a given development phase satisfy the 
requirements imposed at the start of that phase) of electronic 
controllers. Three strategies, labeled open-loop, closed-loop, 
and hybrid, have been developed for systems integration test- 
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ing [37]. The open-loop method directly provides specific input 
sequences to the controller using the scheduler utility. Nor- 
mally, various automotive sensors provide these inputs based 
on the vehicle's powertrain and chassis dynamic behavior. 
Therefore, this test strategy assumes that the vehicle's response 
may be neglected, compensated for, or characterized by the 
prescribed controller inputs in the script files. The closed-loop 
method accepts driver inputs and controller outputs through 
the hardware interfaces to calculate the automobile's behavior 
on the RTS. The advantage of this strategy resides in the 
dynamic coupling of the vehicle dynamics and electronic 
controller to create an environment similar to the actual 
vehicle. Appropriate analytical and empirical models may 
be selected from the simulation library to create a suitable 
dynamic environment. The closed-loop scheduler test files will 
contain driving profiles characterized by typical driver com- 
mands. Finally, the hybrid test method directly manipulates 
select controller inputs per the open-loop method, while a 
closed-loop operating scenario produces the remaining signals. 
This methodology is beneficial in cases where the complete 
set of controller inputs cannot be prescribed, and physical 
relationships must be relied on to generate the remaining 
inputs. 

The simulation laboratory also provides an environment to 
support the design of control strategies and the validation of 
control systems. The stability, sensitivity, and robustness of 
proposed control schemes may be investigated by exercising 
the algorithms in a closed-loop manner on the simulation 
computer without hardware. Control systems may also be 
validated (i.e., the process of evaluating a system at the end 
of the development process to determine whether it satisfies 
the overall systems functional requirements) in this laboratory 
environment. However, the correlation of the results with 
vehicle test data will depend on the accuracy of the various 
system models, as well as the emulation of the actuators and 
sensors. Thus, HIL tools should be viewed as a supplement to 
experimental testing. 

V. Application of the 
Hardware-in-the-Loop Simulation Tool Set 

Experimental and simulation results are discussed to provide 
insight into the underiying system dynamics and application 
of the tool set. Multiple ABS controller variables will be 
presented for an in- vehicle ABS stop, a HIL laboratory sim- 
ulation of the ABS maneuver, and the HIL verification of 
a representative system software requirement. The in-vehicle 
experimental ABS testing was performed in a Saturn SL2 
sedan. A description of the antilock brake control system's 
operation and components may be found in the Saturn service 
manual [43]. A number of tests were completed for various 
road surfaces and vehicle speeds; an ABS stop on dry asphaU 
will be presented. The vehicle was traveling at a speed of V = 
55.0 MPH on a straight course when the brakes were applied 
at tb — 11.70 s. The data collected was limited to the controller 
variables and status bits available through the data logger on 
the MDS instrumentation. In Fig. 7, the brake switch, right 
front (RF) wheel speed (in MPH), commanded RF solenoid 


Fig. 7. In-vehicle ABS maneuver. 

valve state, and RF commanded current (in amperes) are 
displayed. The discrete signals indicate inactive (open) and 
active (closed) states when the brake switch (solenoid lines) 
have a magnitude equal to zero and unity, respectively. For 
convenience, the data is presented between II.O s and 16.0 
s to highlight the ABS stop. In this test sequence, the road 
conditions could not be rigidly controlled which resulted in 
varying surface texture (i.e., no type of uniformity can be 
guaranteed), irregularities, and presence of small debris (i.e., 
stones, gravel, etc.). Therefore, it will not be possible to rigidly 
match the simulation results to this road surface due to these 
nonlinear effects. 

A HIL simulation was created to support software verifi- 
cation at the systems level for the ABS controllers. During 
the tool set development phase, the agreement between the in- 
vehicle and the laboratory simulation results was investigated. 
The appropriate brake modulator, vehicle, and tire/road inter- 
face parameter databases were loaded into the model-based 
simulation. Operating scenarios were created in the laboratory 
similar to those performed in the field. The scheduler utility 
permitted the repeatable simulation of a vehicle traveling at 
approximately V = 55 MPH with the brakes applied at 
tb = 11.70 s. The MDS data logger acquired the same set 
of controller variables and status bits (refer to Fig. 8). To 
compare the in-vehicle and HIL simulated ABS test results, 
several characteristics (e.g., total stopping time, wheel speed 
profile, and commanded current features) will be examined. 
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Fig. 8. Hardware-in-the-Ioop simulation of the ABS maneuver. 
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Fig. 9. Hardware-in-the-loop verification of an ABS controller diagnostic. 


The elapsed stopping times for the in-vehicle and simulated 
RP wheels are 3.16 s and 3.07 s, respectively. Note that the 
wheel deceleration is approximately 26.0 (ft/s^) or 0.8 ^'s 
for the given road surface. The number of impending wheel 
lockup and recovery events is approximately six for each case. 
However, the in-vehicle data also contains a number of minor 
departures, absent from the simulated results, which may be 
partially attributed to nonlinear effects and high-frequency 
unmodeled dynamics. The commanded current profiles for 
the initial ABS release and apply are similar in magnitude 
and duration for each case. The subsequent apply and release 
events differ between the in-vehicle and bench results due 
to the nonlinear and unmodeled dynamics, and the use of a 
different software calibration database which varied the mag- 
nitude of the incremental commanded motor current. Overall, 
the simulation results agree favorably with the in-vehicle test 
results. 

To provide insight into the application of the tool, a short 
to battery diagnostic fault [43] will be verified for the RP 
hydraulic bypass solenoid. During an ABS maneuver, the 
controller provides battery voltage to close the solenoid valve 
and isolate the brake pedal input. Shorting the RF solenoid to 
battery voltage should cause the controller hardware to set a 
fault bit which results in the software disabling of the ABS 
modulator, setting diagnostic code 78, and illuminating the 
ABS telltale light. To verify the diagnostic, a scheduler file 
was created to introduce this fault via the FMTs signal shorting 


circuitry. The controller's variables, as well as the commanded 
FMI introduced fault, were recorded during the simulation. In 
Fig. 9, the brake switch, RF wheel speed, RP solenoid valve 
state, FMI short to battery status (inactive when the magnitude 
is -1), and malfunction 78 flag are presented. The introduction 
of a RP solenoid short to ground at tf^\\ = 12.45 s during 
braking results in the immediate disabling of the ABS system 
and setting of malfunction code 78. 

VL Observations 

A number of observations have been made during the 
development and application of simulation tool sets at Delco 
Electronics. The comments are restricted to simulator re- 
quirements, system hardware/software, and the establishment 
of metrics. Although these categories are not exhaustive, 
they include issues that should be considered eariy in the 
development process. 

A. Simulator Requirements 

A comprehensive set of requirements is essential to identify 
and develop appropriate solutions to meet the simulation 
needs. A variety of simulation products exist ranging from 
PC's with plug in cards to powerfiil simulation computers 
with extensive I/O functions based on VMEbus architecture. 
Clearly, sophisticated models will require a simulator with 
sufficient compute power to calculate the dynamics in the 
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allotted time period. Further, a simulator should be viewed 
as an integral part of the computer aided engineering process 
with provisions for rapid prototyping. 

B. System Hardware/Software 

The hardware interface represents one of the larger expenses 
incurred when developing a simulator. Although vendors now 
offer a variety of interface circuits, the electronic functionality 
required by an application may not be available. Consequen- 
tially, the cost of in-house development (e.g., materials and 
engineering time) or the procurement of commercial solutions 
must be included in the budget. When designing an interface, a 
building block approach with software reconfigurable circuits 
is recommended. 

Software maintenance is a continual task during the life 
cycle of the simulator. A large programming effort will be 
required to create the simulator's software utilities during the 
development phase. To apply the tool set, appropriate system 
models with the required databases should be available on-line. 
In most instances, modifications to the application software 
will be regularly requested to facilitate testing. 

C Establishment of Metrics 

Often the application of sophisticated technologies to the 
product development process must be justified by quantifying 
the cost savings. To measure the direct and indirect benefits 
of a simulation capability on product design and testing, 
appropriate metrics must be established. Some measurable 
quantities that may be selected include changes in manpower 
requirements, level of experimental or in-vehicle testing, and 
warranty return rates. 
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Abstract 

There is considerable interest in the automotive 
industry in computer aided engineering tools that 
support rapid development of quality products. In this 
paper, we describe some of the design and 
implementation issues for such a tool, namely, a 
Hardware-in-the-Loop (HIL) simulator, in the context 
of powertrain control system software development. 
This HIL system is used to verify the production 
powertrain controller module (PCM) performance. 
Hence, the powertrain and driveline dynamics are 
simulated on the HIL hardware and the production 
PCM is the "hardware" in the loop. HIL system 
requirements from the users* and the system 
developer's perspectives are described. The paper 
focuses on important HIL issues related to the real-time 
powertrain models and the hardware signal interfaces. 

1. Introduction 

Automotive engineers are being challenged to deliver 
higher quality products faster with ever shrinking 
resources for global markets with disparate emission 
regulations and customer expectations. The design and 
implementation of control algorithms is a crucial 
element in the development of powertrains to meet 
these requirements. Ad-hoc heuristic design and 
implementation methods are being replaced by 
systematic, requirements driven processes. Vehicle 
requirements are cascaded down to powertrain system 
requirements which in turn generate individual engine 
and transmission subsystem requirements. The goal of 
the powertrain control system development process is 
to generate a production quality control system that will 
be calibrated by system engineers to meet powertrain 
and vehicle requirements in different markets. Due to 
intense competitive pressures, the development times 
are being shortened considerably. The goals of 
delivering a quality product with reduced "time to 
market" constraints cannot be successfully met unless 
modem computer aided tools are judiciously used in the 
development process. This paper describes some 
important issues in the design and development of one 
such tool used in powertrain control system software 
development. 
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Since the PCM hardware is often developed in parallel 
with the control algorithms and the vehicle subsystems, 
developers have little time to test and verify the control 
algorithm implementations. Currently, control systems 
are developed and tested using open loop testers and 
prototype vehicles. The final system validation 
(conformance to requirements) is also performed in 
prototype vehicles at various geographical locations to 
ensure that the controller algorithms are robust- Open 
loop testers have limited functionality for software 
testing since the developer cannot simulate the overall 
system feedback loops (e.g., resulting engine torque 
and speed as a function of changes in spark advance 
and fuel injected). If a "virtual vehicle" were available, 
a significant part of software verification and system 
validation could be completed in a laboratory 
environment 

Hardware-in-the-Loop (HIL) simulation systems 
provide such a "virtual vehicle" for system validation 
and verification. Different HIL configurations have 
been described in the literature for different user 
applications [1,4] based on the "hardware" that is "in 
the loop". The specific HIL system described here 
includes the powertrain control module (PCM) in the 
loop, while the powertrain dynamics, the sensor and 
actuator behaviors are simulated in the computing 
platform and interface circuitry. The PCM **thinks" it is 
in a car. and this allows engineers to validate the 
control system behavior in a "virtual vehicle" 
environment In addition, the controller behavior can be 
validated at various environmental conditions and the 
controller robustness can be tested by introducing 
powertrain component and subsystem malfunctions. 
While a HIL simulator will not obviate the need for 
traditional test methods, it does allow developers to test 
the system in a repeatable laboratory environment. As a 
result developers can identify and resolve problems 
earlier in the development cycle. 

As with any system development the design of HIL 
systems should be driven by requirements. Some of 
these high level requirements are described in the next 
section. There are several hardware and software issues 
that are important for a successful HIL implementation. 
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This paper is focused on those related to real-time 
powcrtrain modeling and signal interfacing and 
conditioning. A majority of the system design activity 
involves sorting out these issues and therefore merits 
detailed discussion. 

2. Requirements for the HIL System 
Since system requirements drive the design and 
influence trade-offs, careful attention has been paid to 
the task of collecting requirements. Requirements can 
be categorized as those from the end user and those 
relating to system development and maintenance. 
Along with these requirements, the available resources 
and system costs will significantly impact the design of 
the system. Some of the high level requirements are 
generic and are independent of the specific powertrain 
application. These include: 

1. The system should be flexible so that it can be used 
in multiple applications with minimal changes. 

2. The system should have sufficient fidelity so that 
controller malfunctions are only triggered under 
the same conditions as in the vehicle. 

3. System debugging tools should be available to aid 
the end user as well as the system developers. 

4. The models should be implemented in an easy to 
use environment that permits reuse and exchange 
of component models between architectures. 

5. The computational platform should be expandable 
to permit fuOire growth without adversely affecting 
the real time throughput of the system. 

6. Use of conrmiercial input/output cards with 
minimal customization is desirable. 

7. Hardware and software interfaces should be **user- 
friendly" so that the end user is comfortable using 
the system. 

8. A modular interface to the controller's physical 
signals is necessary to enable cost effective 
modifications, when required. 



Controller 


Figure 1 : HIL System Components 


3. Configuring and Implementing an HIL System 
Besides the generic requirements described above, 
there may be application specific system requirements. 
All of these requirements should be taken into account 
in the HIL design and implementation process. A block 
diagram representation of the HIL system is shown in 
Figure 1. The following key process steps are involved 
in developing such a system: 

• Identify the specific PCM expectations. 

■ Identify the HIL computational platform. 

■ Identify the modeling tool and generate "WL 
oriented powertrain system models". 

■ Identify, partition and implement interface signal 
transformations and electrical characteristics. 

■ Develop standard test suites 

■ Implement an appropriate hardware and software 
user interface 

Although each of the aforementioned topics is 
important enough to warrant a thorough discussion, this 
paper focuses on two of those topics, namely, the "HIL 
oriented powertrain system models" and signal 
conditioning and interfacing. 

4. HIL oriented Powertrain System Model 
A large part of the HIL development effort is dedicated 
towards assembling a powertrain behavior model. This 
may involve modifying and adapting existing models as 
well as developing new models. The real-time 
simulation models share some unique properties that 
include: 

■ Models include sufficient dynamics to meet the 
requirements of the PCM, but are not detailed 
enough for design purposes. 

■ Systems are typically represented by algebraic or 
ordinary differential equations. 

■ Implicit equations or algebraic loops are not used 
in the models, because these representations 
require an iterative solution process and the real- 
time nature of HIL systems requires fmite 
computation times. 

■ Fixed step size explicit schemes such as Euler, 
trapezoidal or Runge-Kutta methods are chosen as 
the integration algorithm. 

■ Unnecessary units or scaling conversions in the 
model are eliminated to reduce computational 
burden. 

Typically, HIL system models are adapted from 
hardware or control system design models and are 
modified to conform to the above requirements. In 
addition, the models may be extended to react to user 
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triggered faults. The models have been developed in 
SIMULINK** and' STATEFLOW™. 

4. 1 Model Architecture Definition 

One of the first steps in the modeling process is the 
development of a system mode! architecture. The 
model architecture defines and establishes the various 
functional units and the signal interface between the 
units in the model. During the architecture definition 
process, the structural decomposition of the model is 
also decided. At the root level, the model has been 
partitioned into User Inputs, Powertrain Systems, 
Actuators and Sensors. The Powertrain Systems unit is 
further partitioned into Engine, Driveline, Catalyst and 
Accessory Loads. Engine Sensors, Driveline Sensors 
and Accessory Loads Sensors make up the Sensors unit. 
Similarly, the Actuators model unit is partitioned into 
Engine Actuators, Driveline Actuators and Accessory 
Loads Actuators. The Actuators and Sensors are 
connected to Input and Output Hardware Interface units 
respectively. The Hardware Interface units consists of 
specific models of the I/O cards. These models are 
supplied by the platform provider and can be 
progranmied easily from the standard SIMULINK* 
user interface. The User Inputs unit has all the model 
elements (including GUIs) for an interactive 
experiment session. 

4.2. Model DescriptioD 

Typical control oriented models provide adequate 
fidelity for control software validation. Modeling 
standards and rules regarding labeling, units, ranges and 
data types have been established and documented. 
These standards will be invaluable while using and 
updating the models. The models are discretized at a 
sample rate of 1 millisecond for the real-time 
implementation. A brief description of the important 
sub- models follows. 

Engine: This simulation model generates key variables 
such as engine speed, brake torque, intake and exhaust 
manifold pressures, mass air flow through the engine, 
air-fuel ratio of the combustion mixture and exhaust 
temperature and emissions. Modeled subsystems 
include intake manifold dynamics, fuel wall welting, 
engine breathing, intake to powerstroke delay, torque 
generation, exhaust temperature and pressure dynamics 
and feedgas emissions [2,5,7]. 

Driveline: The driveline simulation includes models of 
the torque converter, transmission and the driveline 
dynamics. The torque converter model, which consists 
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of algebraic relationship between pump and turbine 
torques and their rotational speeds, provides the load 
torque to the engine and torque to the downstream 
components. The drive shaft dynamics models the shaft 
torque and turbine speed as a function of the turbine 
torque and driven wheel speed. The driveline inertia is 
lumped into single inertia elements for each of the 
gears in this model. The longitudinal dynamics model 
calculates the vehicle and wheel speeds. 
Catalyst: A three way catalyst model emulates the 
behavior of the exhaust after-treatment system. Key 
elements include an oxygen storage model, catalyst 
efficiency model and a catalyst warm-up model [3]. 
Accessory Loads: Accessories such as air conditioner 
clutch and a power steering pump are modeled to 
generate appropriate loads on the engine crankshaft so 
that realistic engine cranking and start up behaviors are 
simulated. 

Actuators and Sensors: The actuators and sensors are 
the key elements in the model architecture and 
transform physical quantities into electrical signals 
required by the PCM. The actuator and sensor 
electronics can be simulated either in the interface 
hardware or in the SIMULINK** environment. The 
mechanical elements of the sensors and actuators are 
modeled in SIMULINK®. The mechanical behaviors 
are typically represented as static nonlinear functions 
and lags or delays. The effect of malfunctions, 
introduced by the user through either the hardware or 
the software interface are also modeled. 

4.3. Flexible Modeling Environment 

An important system requirement is the ability to 
change individual model elements rapidly between 
experiments. This provides the users with the capability 
of using varying levels of component model complexity 
to debug an undesirable behavior in a system. The 
problem area can be isolated first by choosing simple 
subsystem models and complex models can be used 
subsequently to perform root cause analysis of the 
problem. An user friendly modeling environment based 
on the SIMULINK* library concept has been developed 
to support reusability and flexibility [6]. The use of this 
environment has significantly reduced the time to 
reconfigure models for various applications. 
Additionaly, using a library source to implement a 
model that is used multiple times leads to ease of 
maintenance of the model architecture. 

5. Signal Interfacing and Conditioning 

The identification and implementation of the interface 
between the computing platform and PCM is extremely 
important and very time consuming. Issues related to 
Signal Transformations, Physical Signal Interfacing and 
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simulation of I/O Hardware Fault Conditions have to be 
sorted out. An in-depth knowledge of the PCM circuitry 
and capabilities of the computational platform is 
necessary to address these issues. 

5.1. Transformation Of Signals 
An HIL environment requires signals from the 
computational platform to be interfaced to the hardware 
in the loop. Hence, signal transformations from the 
physical (electrical) domain to engineering units are 
required. As an example, engine fuel injector 
commands are electrical pulses to a solenoid, but result 
in a fuel mass flow rate in the model. Generally, the 
hardware interface signal behavior can be generated in 
one of several ways: 

1. Simulation output on the computing platform 

2. Output of an input-output signal processor card 

3. Output of the custom signal conditioning boxes 

4. Output of a custom hardware circuitry. 

During the design phase, one must decide on the proper 
partitioning of signal processing into available software 
and hardware. This results in a trade-off between 
system complexity, computational burden and 
maintainability. By moving functionality from the 
models to the hardware interface, the computational 
burden is decreased. This will free up computational 
resources to meet the real-time target. However, the 
hardware interface may become more complex and 
may require additional resources to maintain it. In the 
case of the fuel injector example, the primary task is to 
measure the duration of pulses commanded by the PCM 
when the injectors are open. This task is completed in 
several steps. The duration must be measured with 
reference to the crankshaft angular position. There may 
also be an arbitrary number of additional pulses to be 
measured within a finite angular position of the engine 
(e.g. 720 degrees of crank revolution). All of these 
pulses must be summed to represent a total fuel flow 
commanded by the PCM into individual cylinders of 
the engine. To implement the primary task, a designer 
must choose to either let the computational platform 
measure the pulses and generate the rate of fuel flow 
into the engine cylinders, or the hardware may be 
intelligently designed to measure this fuel flow and 
provide this as a scaled engineering unit value to the 
computational platform. 

Another way to resolve the signal transformation issue 
is to have each of several processors in the 
computational platform dedicated to specific tasks. The 
core plant model could be executed in a set of dedicated 
processors while the I/O functionality could be 
partitioned among several other processors. 


5^. Physical Signal Interfacing 

The current state of the art in automotive powcrtrain 
control technology demands that PC Ms interface with a 
wide range of sensors and actuators. It is common to 
see a PCM with 100 to 160 I/O pins and the HIL 
system must provide valid interface for each of these 
pins. 

Powertrain controllers typically contain many types of 
output circuits depending on the automotive 
application. These include low side and high side 
driven lamps, solenoids, and motors. Hiere are also 
requirements for current controlled devices such as 
current controlled solenoids and high current - high 
pressure solenoids. Controller inputs are differential 
variable reluctance sensors (VRS), switch inputs pulled 
up or down within the controller, Hall effect signals, 
and analog voltages from pressure and temperature 
sensors- The following points are important when 
designing the HIL interfaces to these types of signals: 

1. Some solenoid or current controlled driver circuits 
require feedback. For example, some drivers 
require a load inductance because they use 
switching circuits to control the current. In other 
cases, the flyback voltage from an inductive 
actuator may be used to perform diagnostics on the 
actuator. These special cases must be 
accommodated by the HIL system to prevent 
unintentional fault conditions from being detected. 

2. In many cases, current sensor technology provides 
simple analog voltage outputs for temperatures and 
pressures. In most cases, these signals may be 
simulated by using digital to analog (DAC) drivers 
in the HIL system. 

3. Where possible, the HIL system should utilize 
some form of arbitrary waveform generation for 
VRS signals. This will allow users to simulate 
fault conditions for these signals. 

4. The interfacing requirements of the driver circuitry 
within the PCM needs to be understood. In many 
cases, output loads can be simulated with simple 
resistive loads as long as the normal operating 
currents are preserved for the driver circuits. 

5. Key elements in the simulated load circuitry should 
be easy to modify. Sockets for resistive loads, 
separation of solenoids or inductors into functional 
'packs* (e.g. simulated fuel injector inductors) that 
can be swapped are two examples of how this will 
be accomplished. This will ensure that the HIL 
system can accommodate as many conu^ller 
applications as possible. 
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To illustrate some of the points described above, an 
implementation of a simple resistive low side driven 
actuator is shown in Figure 2. In this case, the fault 
simulation block (see Section 5.3)> voltage level 
conversion, and noise immunity may reside in one 
system enclosure. The load, Rload, may reside in a 
separate load simulation enclosure with other simulated 
actuators, and the HIL system I/O hardware may be 
another enclosure which utilizes comm^cially 
available hardware (e.g. timer/counter capture circuits. 
A/D circuits. DAC circuits, arbitrary waveform 
generators, etc.). 

5.3. Signal Fault Simulation 

Automotive powertrain controllers utilize many 
intelligent integrated circuits for driving actuators and 
monitoring sensor outputs. This intelligence is 
necessary to accomplish self diagnosis of fault 
conditions. In many cases, these diagnostics must be 
executed during normal operation of the PCM software. 
PCM software verification requires that the software be 
tested under normal and abnormal modes. Since the 
abnormal modes of operation are tested under control, 
the HIL system must have the ability to force fault 
conditions for appropriate controller signals under 
automatic control. Typical fault conditions encountered 
in automotive environments are listed below: 

1. Short to ground - A controller signal has been short 
circuited to ground. 

2. Short to battery voltage - A controller signal has a 
low resistance path to vehicle battery voltage. 

3. Open circuit - A controller signal has no path to 
ground. 

4. Shorted load - A controller actuator has been 
shorted to ground (the difference between this and 
a short to ground is whether an actuator is driven 
from the high side or low side). 

In Figure 2. the Fault Simulation block shows a method 
of implementing fault generation in a HIL system. In 
this case, fault simulation is the last layer of hardware 
interface to the PCM signal. The fault simulation is 
accomplished through a series of relays which may be 
controlled by the HIL simulator. These relays will 
alternately switch the PCM signal to either of the fault 
conditions or complete the signal path to the HIL 
simulator. 

6. Conclusions 
The task of putting together a flexible HIL system for 
verification of production PCM performance is 
significant. In this paper, we have addressed two 
important HIL system aspects related to the real-time 
models and the hardware signal interface. Based on our 
experience, these two issues require a great deal of 


attention in the early stages of development and are 
critical to the success of Hn^ based product 
verification. Implementing the real-time model 
infrastructure involves structure identification, 
parametrization and validation. The model structure has 
been described here. Parametrization and validation 
procedures are resource intensive and require extensive 
powertrain data. This will be the subject of a ftinire 
publication. Hardware signal interfacing and 
conditioning is a very complex and time consuming 
activity. Having a good signal interface design and 
implementation will result in a well controlled system 
test. This paper has identified several critical factors 
needed to achieve a robust signal interface to the PCM. 
Further details on die HIL system along with the results 
of HIL based testing will be reported in a separate 
paper. 
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